Co-authored-by: Thomas Lively <[email protected]>

…m:hedwigz/emscripten into inline-javascript-sync-awaitable-promises

…ripten-core#23029)

These two options are not compatible, and `GLOBAL_BASE` is currently
just ignored in this mode.

…ipten-core#23039)

% `codespell --ignore-words-list=dum,implementor,tre --write-changes
tools`
* https://pypi.org/project/codespell

emscripten-core#23025)

In linux, `mkdir("some_file/dir")` returns `ENOTDIR` but Emscripten
returns `EPERM`. This fixes it.

Related:
https://discourse.cmake.org/t/error-when-crosscompiling-with-whole-archive-target-link/9394

whole-archive support needs to be explicitly declared in toolchain file,
see cmake official
[GNU](https://github.com/Kitware/CMake/blob/6be01c932e077306ebea15cef4b8befb29c5130e/Modules/Platform/Linker/GNU.cmake#L35-L44).

The engines that support memory64 now all also support table64.

This removes the recursion from `lookupPath` and in my opinion makes the
control flow much more explicit and comprehensible.

See emscripten-core#23045

This is an internal function that should not have any external users.

emscripten-core#23063)

…mscripten-core#23064)

…ore#23049)

We were incorrectly reporting non-existent parent directories as
non-writable.

This was broken in emscripten-core#22801.

WebAssembly/binaryen#7153 updated Binaryen
version to 121, but bumping the version to 121 here does not pass the CI
(because Binaryen version is behind by 2), so this updates the version
to 120 for the moment.

…ds (emscripten-core#23177)

- @with_all_fs
- @also_with_nodefs
- @also_with_nodefs_both

…re#23191)

…e#23203)

Fix the signatures of several native wasmfs exports. These are only
needed/relevant under wasm64.

This change removes the need for `runCaller` and the `calledRun` global.
Instead we simply set `dependenciesFulfilled` to `run` directly each
time to return early due to outstanding dependencies.

This also means that we don't need a reentrancy check on `doRun` since
`dependenciesFulfilled` is only set in the case where `doRun` didn't
actually run.

This both simplifies the code and saves on code size.

…ten-core#23204)

It seems like the underlying issue with the mac package has been fixes
somehow, and I was running into issues with this version of lxml not
being installable on python 3.12 (which is in ubuntu-latest on github
CI).

See emscripten-core#19785

This is an automatic change generated by tools/maint/rebaseline_tests.py.

The following (2) test expectation files were updated by
running the tests with `--rebaseline`:

```
browser/test_small_js_flags.js.size: 4327 => 4297 [-30 bytes / -0.69%]
other/test_INCOMING_MODULE_JS_API.js.size: 3758 => 3710 [-48 bytes / -1.28%]

Average change: -0.99% (-1.28% - -0.69%)
```

This test will fail if the expectations are out-of-date on the main
branch. This can happen due to either:

1. Somebody forgetting to update the expectations when they land an
emscripten change
2. llvm or binaryen changes that rolled in on the auto-roller.

For now I propose that we don't make this new check "Required" and we
consider this the first step towards making these updates easy and
automatic.

I made this a github action rather than using CiricleCI since I
anticipate using github automation here in the future (for example to
suggest updates the current PR).

…re#23206)

Firstly the bug has a been fixed. Secondly, the warning is no longer
up-to-date with the code and it looks like someone would have to do
`-sEXPORT_NAME=moduleArg` to hit this name collision now.. which seems
more than unlikely.

WebAssembly/binaryen#7153 updated Binaryen
version to 121, and we updated it in Emscripten to 120 to make the CI
pass (emscripten-core#23197). Now that
https://chromium-review.googlesource.com/c/emscripten-releases/+/6103023
has landed, I think we can update it to 121.

…ten-core#23208)

I think this makes it a little easier to follow.

Before this change `mkdir("a/b/..")` surprisingly makes a directory
called `a/b/a`. It should raise EEXIST.

I don't think there any any other codesize tests that cover this.

…core#23150)

Followup to emscripten-core#23104

…m:hedwigz/emscripten into inline-javascript-sync-awaitable-promises